What kind of change does this PR introduce?

Refactor of Audio Processor class which applies to this plugin implementation, not to the DSP library.

• Useage of array/vector/container for biquad DSP array, enabling multi-band equalization
• Useage of std::unique_ptr to carefully manage ownership and lifetime of instantiated class objects
• Useage of returning managed class private members by reference, via function call return statements, specified as public or private according to requirements (most of these things should always be private unless a good, well-understood reason otherwise)
• Localized references to managed objects within function bodies where possible, by using the function call returns, instead of calling managed objects directly
• Reduction of (un-managed) calls to *this in the main AudioPluginAudioProcessor class constructor
• Re-organization of ownership of parameters, process wrapper, APVTS, header inclusion paths, and class declaration logic
• Project re-organization
• Additional CMake targets for individual units of the Biquads_Audio_Plugin target, for deeper debugging

What is the current behavior?

• Some confusing logic re: ownership and lifetime of objects
• Pointers/references to forward-declared objects has led to some redundancy and potential for mis-direction
• Lack of iterations over biquad DSP processing blocks causing audio artefacts
• Project is not fully compatible between CMake and Projucer due to project layout requirements of Projucer